1. Technical Field
The present invention relates to the field of telephony voice processing, and more particularly, to generic service components for accessing voice processing services.
2. Description of the Related Art
The development of the open network application programming interface (API) represents an important departure from traditional methods for opening the architecture of the public switched telephone network (PSTN). Presently, the Advanced Intelligent Network (AIN) architecture defines a call model which allows the creation of telecommunications service applications outside of the switch environment. Telecommunications service applications are a la carte telecommunications applications which can perform enhanced services for a telecommunications session established among two or more parties. Exemplary service applications can include Call Waiting, Caller ID, Call Forwarding, Voice Activated Dialing, and Meet-me Conferencing.
When AIN first was introduced, in terms of the service application creation process, the AIN architecture represented an important advance. AIN separated service development from switching, allowing service logic components to be developed more quickly and placed in specialized network elements attached to databases. Switches, in turn, being free from all service logic, could be optimized for speed and efficiency. Still, typical service applications developed to the AIN specification are written in specialized languages by specially trained programmers using specialized service creation environments.
Importantly, future telecommunications networks will be characterized by new and evolving network architectures where packet-switched, circuit-switched, and wireless networks are integrated to offer subscribers an array of innovative multimedia, multiparty applications. Equally important, it is expected that the process by which telecommunications applications are developed will change, and will no longer solely be the domain of the telecommunications network or service application provider. In fact, in order to provide a broad portfolio of novel, compelling applications rapidly, service application providers will increasingly turn to third-party applications developers and software vendors. Thus, application development in the telecommunications domain will more closely resemble that of software and information technology in general, with customers reaping the benefits of increased competition, reduced time to market, and the rapid leveraging of new technology as it is developed.
In accomplishing this goal, a new service application component development paradigm has been established. Specifically, it has been recognized that future integrated networks must offer application developers a set of standard, open APIs so that applications written for compatibility with one vendor's system can execute in the system of another vendor. In consequence, the cost of applications development can be amortized, reducing the final cost to the customer. Java APIs for Integrated Networks (JAIN®) fulfills the requirements of the new service application component development paradigm. Presently, JAIN includes standard, open published Java APIs for next-generation systems consisting of integrated Internet Protocol (IP) or asynchronous transport mode (ATM) networks, PSTN, and wireless networks. The JAIN APIs include interfaces at the protocol level, for different protocols such as Media Gateway Control Protocol (MGCP), Session Initiation Protocol (SIP), and Transactional Capabilities Application Part (TCAP), as well as protocols residing in the higher layers of the telecommunications protocol stack.
JAIN includes a set of integrated network APIs for the Java platform and an environment to build and integrate JAIN components into services or applications that work across PSTN, packet and wireless networks. The JAIN approach integrates wireline, wireless, and packet-based networks by separating service-based logic from network-based logic. FIG. 1 illustrates a conventional JAIN implementation. As shown in FIG. 1, a conventional JAIN implementation can include a protocol layer 105 which can include interfaces to IP, wireline and wireless signaling protocols. These protocols can include TCAP, ISUP, INAP, MAP, SIP, MGCP, and H.323. The JAIN implementation also can include a signaling layer 110 which can include interfaces to provide connectivity management and call control. The conventional JAIN implementation also can include an application layer 115 for handling secure network access and other external services. Finally, the conventional JAIN implementation can include a service layer 120 which can include a JAIN compliant service creation and carrier grade service logic execution environment (JSLEE) 125.
In JAIN, the protocol layer 105 and the signaling layer 110 are based upon a Java standardization of specific signaling protocols and provide standardized protocol interfaces in an object model. Additionally, applications and protocol stacks can be interchanged, all the while providing a high degree of portability to the applications in the application layer using protocol stacks from different sources. By comparison, the application layer 115 provides a single call model across all supported protocols in the protocol layer 105. Fundamentally, the application layer 115 provides a single state machine for multiparty, multimedia, and multi-protocol sessions for service components in the application layer 115. This state machine is accessible by trusted applications that execute in the application layer 115 through a call control API.
Notably, applications or services executing at the application layer 115 can communicate directly with protocol adapters in the JSLEE 125. Protocol adapters typically are class methods, callbacks, event or interfaces that encapsulate the underlying resources such as TCAP, MGCP, etc. The underlying resources can be implemented in many programming languages, but a JAIN-conformant protocol product must provide at least the relevant JAIN API. In contrast, an external application or service executing in the application layer 115 does not have to be aware of the underlying resources and can remain oblivious to the fact that some of its session or call legs may be using different protocols.
Service components 130 are the core JAIN components and can execute in the JSLEE 125. More particularly, service components 130 are constructed according to a standard component model, and instantiations of component assemblies can execute in coordination with the JSLEE 125. Using information regarding the protocol layer 105 which can be incorporated into the JSLEE 125, service components 130 can interact with the underlying protocol stacks without having specific knowledge of the protocol stack. The service components 130 can use the call model provided by the application layer 115 to implement telephony services. More importantly, the JSLEE 125 can relieve the service components 130 of conventional lifecycle responsibilities by providing portable support for transactions, persistence, load balancing, security, and object and connection instance pooling. In this way, the service components 130 can focus on providing telephony services.
Despite the advantages provided by JAIN, however, the development of a telecommunications service application still requires knowledge of many disparate communications interfaces and protocols for accessing the service components 130 and various service applications. For example, service applications such as call blocking or call forwarding, and service components for accessing the call model, can require access to voice processing services available from voice processing platforms. Accordingly, though service components 130 of the prior art can provide a standard component model for accessing the signaling layer 110, a telecommunication service application developer still needs a familiarity with the many disparate protocols for accessing voice processing platforms and other telephony functions such as directory services to successfully develop a telephony service application.
For example, conventional voice processing platforms communicate with service application logic through the use of an agreed upon messaging protocol. That is, for a voice processing platform to be used by application service logic operating over an intelligent network, the application service logic must support the particular protocol utilized by the voice processing platform. In consequence, the number of persons having the necessary expertise to develop a telephony service application can be limited. As the service application becomes more complex, requiring access to more service functions such as directory services and voice processing services, each using a different messaging protocol, the availability of skilled personnel decreases. The highly specialized nature of telephony service application development can result in increased developmental expenses and longer design cycles.
Further, the complexities involved make it difficult to port systems, features, and applications across diverse hardware and/or software environments. For example, because the protocol and logic necessary to access a particular service functionality are included within the service application being developed, any changes to an underlying protocol can necessitate reprogramming of the entire service application. To migrate a given telephony application to another hardware and/or software environment, the telephony application must be redesigned and/or recoded to work with the particular messaging protocol utilized by the voice processing platform with which the telephony application is to be used.